IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services which are considered in more detail below.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. The main IMS specification is TS24.229. IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network. Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
A user registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. The user receives a unique URI from the S-CSCF that it shall use when it initiates a dialog. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates an S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions which would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF if one is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. [It is noted that S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF.] When a registered user subsequently sends a session request (e.g. SIP INVITE) to the IMS, the request will include the P-CSCF and S-CSCF URIs so that the P-CSCF is able to forward the request to the selected S-CSCF. This applies both on the originating and terminating sides (of the IMS). [For the terminating call the request will include the P-CSCF address and the UE address.]
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment. Different IFCs may be applied to different call cases. The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's User Profile. Certain Application Servers will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the Application Server). For example, in the case of call forwarding, the appropriate (terminating) application server will determine the new terminating party to which a call to a given subscriber will be forwarded.
The working group known as ETSI TISPAN initially developed the use of IMS for fixed broadband accesses, although this task has now been passed to 3GPP. One of their tasks is to develop supplementary services based upon the IMS defined by 3GPP. These supplementary services will be defined in separate specifications although they will impact upon core specifications such as TS24.229. FIG. 2 illustrates schematically the message flow within the IMS for a SIP INVITE, on the call originating side, according to TS24.229 (chapter 5.4.3.2). At step 1), the INVITE is sent from the originating User Equipment (UE) to the P-CSCF. This INVITE includes in its header a so-called P-Preferred identity, as well as including the URI of the P-CSCF at the topmost level of the SIP route header and the URI of the S-CSCF as the second entry. The UE also includes the identity of the communicating partner in the Request-URI. Upon receipt of the INVITE, the P-CSCF checks that the originating UE is allowed to use the identity included as the P-Preferred identity, and if so includes it as the P-Asserted Identity in the outgoing INVITE. The P-Asserted Identity is an identity that is used among trusted SIP entities, typically intermediaries, to carry the identity of the user sending a SIP message as it was verified by authentication. The P-CSCF identifies the S-CSCF allocated to the originating UE by looking in the Route Header, and at step 2) forwards the amended INVITE to that S-CSCF.
The S-CSCF handles the call according to an originating call case procedure. The S-CSCF uses the P-Asserted Identity to check whether any relevant restrictions have been placed on the originating UE, e.g. is the UE barred from using the requested service. The S-CSCF also uses the P-Asserted Identity and call case to determine the IFCs for the UE. In the example of FIG. 2, it is assumed that the IFCs require that the S-CSCF forward (step 3)) the INVITE to a particular AS. The S-CSCF includes at the topmost level of the SIP route header the URI of the AS. It also includes in the subsequent level its own URI, together with an Original Dialog Identifier (ODI). The ODI is generated by the S-CSCF and uniquely identifies the call to the S-CSCF. The AS will itself perform authentication, for example based upon the P-Asserted Identity contained in the message (the originating case). The appropriate case is identified to the AS by the S-CSCF (e.g. by sending the message to an appropriate port of the AS). When the AS returns the INVITE (step 4)) to the S-CSCF, the AS strips the URI of the AS from the route header, leaving the URI of the S-CSCF together with the ODI tag. The ODI tag allows the S-CSCF to determine that the INVITE relates to an earlier dialogue.
It is possible for the AS logic to require the setting up of a new session, in which case it would be necessary to provide a mechanism which allows the AS to replace the original R-URI with the URI of the new terminating User (the existing TSs do not as yet provide for this re-routing scenario). In this case, the identity of the origin, i.e. the P-Asserted Identity of the INVITE at step 4), can be either the identity of the originating UE, the identity of the AS, or an identity of a third party on whose behalf the AS is setting up the new session. In this case, the S-CSCF will repeat the call restriction check and determine the IFCs based upon the P-Asserted Identity contained in the “new” INVITE, assuming that the originating case is used. However, it is possible that the AS may signal to the S-CSCF that the terminating case is to be used, in which case the checks are carried out using the R-URI of the INVITE. Assuming that no further ASs are to be linked-in based upon the IFCs, the S-CSCF forwards the INVITE to the Request URI (R-URI) contained in the INVITE. This may be the R-URI contained in the original INVITE, or a new R-URI contained in the new INVITE if that is different.
FIG. 3 illustrates schematically the message flow within the IMS for a SIP INVITE on the call terminating side (TS24.229: chapter 5.4.3.3). At step 1), the INVITE arrives from the I-CSCF (not shown) including the R-URI indicating the called party. The S-CSCF uses this R-URI to check for restrictions placed on the called party, and to obtain the IFCs. In this case, the IFCs do not indicate that an AS needs to be contacted. The S-CSCF will acquire the preloaded Route Headers for the called party, based on the R-URI, and send the INVITE forward to be UE based on these Route Header entries. The INVITE is received by the P-CSCF in accordance with the preloaded route in the S-CSCF, and the P-CSCF sends the INVITE to the UE in accordance with the contact header.
FIG. 4 illustrates an alternative INVITE message flow scenario, where a call from an originating terminal (UE-O) to a peer terminal (UE-F) is forwarded to a terminating terminal (UE-T). The call forwarding action is performed by an Application Server (AS-F). The call flow is as follows:
1) The INVITE is sent from UE-O addressed to UE-F (R-URI). The S-CSCF O performs the originating side call procedure as described with reference to FIG. 2.
2) After interaction with the AS-O (no change is made to the R-URI at this stage) the S-CSCF O sends the INVITE to the I-CSCF (not shown) of UE-F's home network. The I-CSCF will acquire the address of the S-CSCF where the UE-F is registered from the HSS. The INVITE is sent to that S-CSCF, i.e. to S-CSCF F. The S-CSCF F will check the restriction requirement and obtain the IFCs as described above (for the terminating side case) with reference to FIG. 3, i.e. based on the R-URI contained in the INVITE. In the scenario illustrated in FIG. 4, the INVITE will be sent to the AS-F where the call forwarding is activated.3) The AS-F will then change the R-URI in the INVITE header from that of UE-F to that of UE-T. The modified INVITE will be returned to the S-CSCF F.4) The S-CSCF F will send the INVITE to the I-CSCF of the UE-T network, and the I-CSCF (not shown) will interrogate the HSS to get the address of the S-CSCF T of UE-T, and forward the INVITE to the S-CSCF T.5) The S-CSCF T will perform the terminating procedure as described with reference to FIG. 3, on the basis of the R-URI contained in the INVITE (that is the R-URI of UE-T)
As mentioned above, an Application Server may be required to perform an authorisation on one of the parties associated with the call, before returning a SIP message to the S-CSCF. Whilst this may be straightforward in the case of the originating and terminating cases of FIGS. 2 and 3, the situation is more complex in the call forwarding case of FIG. 4 as the Application Server does not implicitly know which case to apply for which user. WO2007060074 describes a solution to this problem, proposing that, upon receipt of a SIP message at an S-CSCF and following a decision to forward the message to an AS, the S-CSCF introduce a new header into the message referred to as a “P-Served-User”. The proposal is also detailed in the IETF draft: http://tools.ietf.org/wg/sipping/draft-vanelburg-sipping-served-user-05.txt. The role of the new header is to explicitly identify the user that is being served by the S-CSCF and the session case associated with the call for the served user. Whilst in the simple call originating case (FIG. 2) and call terminating case (FIG. 3) the new header will contain the SIP URI of the originating and terminating users respectively, in the case of the call forwarding scenario (FIG. 4), considering S-CSCF F, the header will contain the URL of the forwarding terminal, i.e. UE F. The header will also likely indicate either the originating or terminating call case, and whether or not UE-F is registered with the S-CSCF. An example header might be:                P-Served-User: <sip:bob@home2.net>;sesscase=orig;regstate=reg        
Use of the P-Served-User allows the Application Server to apply a more appropriate authorisation procedure to the message.
Considering further the call forwarding scenario, FIG. 5 illustrates the case where a SIP INVITE originating at a user A (not shown in the Figure) is received for user B at an S-CSCF, message 1. The Filter Criteria are evaluated by the S-CSCF and AS-1 is invoked by the sending of message 2. The S-CSCF includes the P-Served-User header to ensure that the correct served user is identified to the Application Server. AS-1 determines that the INVITE should be diverted to a user C. The Request URI is modified to include C as the target of the request (R-URI), message 3. Changing the Request URI in this way causes the S-CSCF to break the Filter Criteria chain with the result that any additional terminating services for user B are not performed upon receipt of message 3 at the S-CSCF. The S-CSCF is instructed to carry out originating services for user B by including the ‘orig’ parameter in the PSU header in message 3. Alternatively, this could be indicated in the top route header. Evaluation of the originating filter criteria for user B at the S-CSCF invokes AS-2, message 4, which performs the Originating Identity Restriction (OIR) service on behalf of user B (OIR and the related OIP service are considered in 3GPP TS24.607).
A result of the OIR service is the inclusion within the message header of user B's privacy settings, namely the “header” and “id” parameters to indicate to downstream nodes performing the OIP service that user identities within the P-Asserted Identity and other header fields should be hidden. These settings are included in the INVITE sent to the S-CSCF, message 5. The S-CSCF forwards the INVITE to C, message 6, maintaining the privacy settings of user B. This will result in a downstream OIP service deleting user A's identity from the message header, despite the fact that user A is happy to reveal its identity to the end receiver, as exhibited by the presence of the parameter “none” in the privacy header of the original request.